Method And System For Messaging And Communication Based On Groups

ABSTRACT

Systems and methods providing users with a rich web experience are disclosed. In one embodiment, a client and at least one server are in communication using a dual communication link. In another embodiment, a markup language based instant messaging application is disclosed. The instant messaging application may include group instant messaging. The instant messaging application may also provide group member persistence and message persistence at the server. In another embodiment, a card based web application is disclosed, where the card information and character may be shared with other users or within a group. The cards may also be configurable by users.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.60/778,609, filed on Mar. 3, 2006, entitled “Method And System ForMessaging And Communication Based On Groups,” the entire contents ofwhich are incorporated herein by reference.

BACKGROUND OF THE INVENTION

This disclosure relates in general to network communication applicationsand servers and, but not by way of limitation, to group messagingapplications and servers amongst other things.

Web browsers and web-based instant messaging applications typically relyon push/pull methodologies or timers to re-download and display a webpage or instant message. Web browsers, in particular, often use refreshand/or reload functions to request an already displayed web page inorder to display the most up-to-date information. In particular, socialnetworking pages often undergo regular modification and may requireregular reload and/or refresh by a web browser in order to maintain themost up to date information. Moreover, web-based instant messaging (IM)applications also require a reload request prior to having data pushedto the application. Refresh/reload functions and timers require the webbrowser (or web application) to request a web page from the server. Thesystems do not permit instantaneous reload of content. Rather, timersrequest updated information at set intervals, and refresh/reloadfunctions require user interaction. Some non-web-based IM applicationsuse an open channel for rich text based messaging. Most IM applicationshave very little or no message persistence and/or group persistence.

Instant messaging applications typically only display instant messagesin text or rich text formats. Such formats limit the interaction andrichness of the instant messaging experience by not providing forcustomization, applications, and/or embedded media—particularly based onan open standard like HTML. Moreover, instant messaging applications areuser-based. That is, messages are sent from user to user. Furthermore,instant messaging applications do not provide significant degrees ofpersistence for instant message conversations or for groups. Often,closing an IM application results in the loss of conversations and/ordata as well as group membership.

There is a need in the art for a more interactive web browsingapplication as well as a more persistent, group, media & HTML-capableinstant messaging application.

BRIEF SUMMARY OF THE INVENTION

In one embodiment of the invention a network communication method at aclient with at least a first file is disclosed. The method includesestablishing a first and second connection between the client and aserver and receiving a message from the server through the firstconnection. The first connection may include an open connection and thefirst and second connections are not necessarily established at the sametime The first message may instruct the client to request first updatedata from the server through the second network connection.

A network communication method at a server with at least a first file isdisclosed according to another embodiment of the invention. The methodincludes establishing a first connection between a first client and theserver, receiving first update data from the first client through thefirst connection and updating the first file with the first update data.The method may also include establishing a second and a third connectionbetween a second client and the server, sending a message to the secondclient through the second connection, receiving a message from thesecond client through the third connection, and sending the first updatefile through the third connection to the client. The second connectionmay be an open connection and the connections are not necessarilyestablished at the same time. The message may tell the client that firstupdate data is available at the server. The method may further includeestablishing a plurality of second and third connections between theserver and each of a plurality of clients. The plurality of firstconnections may be open connections and the connections are notnecessarily established at the same time. The method may also includesending a message to each of the plurality of clients through each ofthe plurality of second connections. The message may tell each of theplurality of clients that first update data is available at the server.The method may include receiving a message from at least one of theplurality of clients through at least one of the plurality of thirdconnection and sending the first update file through the thirdconnection to each of the plurality of clients that sent a message tothe server. The message may request that the server send the firstupdate file.

Another network communication method at a server is disclosed accordingto another embodiment of the invention. The method includes maintaininga first group list at the server. The first group list may comprise alist of more than one clients including at least a first client, andmaintaining at least a first file at the server. The method alsoincludes establishing a plurality of first connections between theserver and a plurality of clients, sending the first file to the clientsin the first group, and establishing a plurality of second connectionsbetween the server and the plurality of clients. The plurality ofclients comprise at least the first client. The plurality of secondconnections may comprise open connections. The method may furtherinclude receiving a first message from the first client. The firstmessage comprises an addendum to the first file, and the first messagespecifies that the message is intended for clients in the first group,appending the first file with the first message, determining which ofthe plurality of clients with a second connection are in the first grouplist, and forwarding the message to the plurality of clients in thefirst group list through the plurality of second connections.

A persistent group messaging system is disclosed according to anotherembodiment of the invention. The system may include a network interface,a user interface, and a processor. The network interface may be adaptedto communicate with a server through one or more communication links.The user interface may be adapted to communicate with a user. The memorystorage device may include instructions for the processor. The processorinstructions may include instructions to retrieve at least one groupmessage file from the server through the network interface andinstructions to display more than one conversation at the userinterface. The group message file may include more than oneconversation.

An instant messaging application is disclosed according to oneembodiment of the invention. The instant messaging application mayinclude a network interface, a user interface, and a processor. Thenetwork interface may be adapted to communicate with a server throughone or more communication links. The user interface may be adapted tocommunicate with a user. The memory storage device may includeinstructions for the processor. The instructions may includeinstructions to receive instant messages from the server through thenetwork interface, instructions to display the instant messages at theuser interface; and instructions to display ads at the user interface.The ads may be related to the content within the instant messagespresently displayed at the user interface and as the instant messageconversation progresses and the content changes the ads likewise changeto adapt to the changed content.

A group instant messaging application is disclosed according to oneembodiment of the invention. The group instant messaging application mayinclude a network interface, a user interface, and a processor. Thenetwork interface may be adapted to communicate with a server throughone or more communication links. The user interface may be adapted tocommunicate with a user. The memory storage device may includeinstructions for the processor. The instructions may includeinstructions to receive more than one instant message conversation fromthe server through the network interface, and instructions toconcurrently display more than one instant message conversation at theuser interface. The instant messages may comprise messages from morethan one user and comprise more than one conversation.

A network communication apparatus is disclosed according to oneembodiment of the invention. The network communication apparatus mayinclude a web user agent in communication with a web server, and aninstant messaging client in communication with an instant messagingserver over an open connection. The instant messaging client may receivea message from the instant messaging server informing the networkcommunication apparatus that an updated file is available at the webserver and the web user agent requests and receives the updated filefrom the web server.

A network communication server is disclosed according to one embodimentof the invention. The network communication server may include an openconnection server and a persistent data server. The open connectionserver may include an instant messaging client in communication with aninstant messaging server. The persistent data server may include aninstant messaging client in communication with an instant messagingserver and a web server in communication with at least one web client.

An instant messaging method at a first client is disclosed according toone embodiment of the invention. The method may include receiving awidget from a user, associating the widget with a button at a clientapplication associated with the first client, and distributing thewidget to a second client through a network interface. The method mayfurther include receiving a second widget from a third client andassociating the widget with a button at a client application associatedwith the first client.

Further areas of applicability of the present disclosure will becomeapparent from the detailed description provided hereinafter. It shouldbe understood that the detailed description and specific examples, whileindicating various embodiments, are intended for purposes ofillustration only and are not intended to necessarily limit the scope ofthe disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a client in communication with a server employing twocommunication schemes according to one embodiment of the invention.

FIG. 2 shows a plurality of clients in communication with a serveremploying two communication schemes according to one embodiment of theinvention.

FIG. 3 shows JABBER and HTTP connections, interfaces and servers in acommunication system according to one embodiment of the invention.

FIGS. 4A and 4B show block diagrams of a group instant messaging serverin communication with a group messaging application according to oneembodiment of the invention.

FIG. 5 shows a flowchart describing a method of instantly displayingupdated data at a client system in a network configuration according toone embodiment of the invention.

FIG. 6 shows a flowchart describing a method of instantly displayingupdated data at a client system in a network configuration according toone embodiment of the invention.

FIG. 7 shows a flowchart describing a method of instantly displayingupdated data at a client system in a network configuration according toone embodiment of the invention.

FIG. 8 shows a flowchart describing a method of managing an instantmessaging server according to one embodiment of the invention.

FIG. 9 shows a flowchart describing a method of managing an instantmessaging server according to one embodiment of the invention.

FIG. 10 shows a flowchart describing a method of managing a groupinstant messaging server according to one embodiment of the invention.

FIGS. 11A-C show a method of determining whether a new user mayparticipate in a group according to one embodiment of the invention.

FIGS. 12A-C show screenshots of various features of a group messagingapplication according to one embodiment of the invention.

FIG. 13 shows a screenshot of a pop-out card of a group messagingapplication according to one embodiment of the invention.

FIG. 14 shows a screenshot of a welcome screen of a group messagingapplication according to one embodiment of the invention.

FIG. 15 shows a screenshot of a decision window of a group messagingapplication according to one embodiment of the invention.

FIG. 16 shows a screenshot of a card editor of a group messagingapplication according to one embodiment of the invention.

FIG. 17 shows a screenshot of a popular groups window of a groupmessaging application according to one embodiment of the invention.

FIGS. 18A-F show screenshots of a user profile of a group messagingapplication according to one embodiment of the invention.

FIG. 19 shows a screenshot of a group profile of a group messagingapplication according to one embodiment of the invention.

FIG. 20 shows a screenshot of group settings of a group messagingapplication according to one embodiment of the invention.

FIGS. 21A-C show screenshots of a user invitation window a groupmessaging application according to one embodiment of the invention.

FIG. 22 shows a screenshot of group booting window of a group messagingapplication according to one embodiment of the invention.

FIG. 23 shows a screenshot of a premium group settings of a messagingapplication according to one embodiment of the invention.

FIG. 24 shows a screenshot of a group creation window of a groupmessaging application according to one embodiment of the invention.

FIGS. 25A-D show screenshots of card management, editing and sharingaccording to one embodiment of the invention.

In the appended figures, similar components and/or features may have thesame reference label. Further, various components of the same type maybe distinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If only the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

DETAILED DESCRIPTION OF THE INVENTION

The ensuing description provides preferred exemplary embodiment(s) only,and is not intended to limit the scope, applicability or configurationof the disclosure. Rather, the ensuing description of the preferredexemplary embodiment(s) will provide those skilled in the art with anenabling description for implementing a preferred exemplary embodiment.It being understood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope asset forth in the appended claims.

In one embodiment, the present disclosure provides for a web applicationthat instantly refreshes a web page when the web page has been updatedat the server. The application is in communication with the server overtwo communication links: an HTTP communication link and an opencommunication link. The web page is transmitted over the HTTPcommunication link, after which the HTTP communication link may beclosed. The application may be alerted that the web page has beenupdated through the open communication link, whereupon the applicationrequests the updated web page from the server. In other embodiments, theopen connection transmits web page updates or the updated web page.Accordingly, updates to web content occur substantially instantaneouslywithout reload, refresh or timers. Web content may include instantmessaging services, file transfer services, and/or media sharing.

In yet another embodiment, the present disclosure provides forpersistent group messaging. Groups are persistent in that groupmembership is stored and saved on a server. Group members may haveaccess to a group including group messages and/or content throughout theexistence of the group regardless of when the group members are onlineand/or regardless of which computer the user uses to connect to theserver. Messages are persistent in that messages are stored and saved ona server. Group members may have access to the messages and may commentand amend messages at any time. When group members are online groupmessages may occur substantially instantly.

Referring first to FIG. 1, a dual communication system is disclosedaccording to one embodiment of the invention. A client 110 is incommunication with a server 120 over two communication links 130, 140.The communication links 130, 140 may be different communication schemes.For example, the communications links 130, 140 may communicate usingHTTP and/or JABBER protocols. Moreover, any application layer protocolmay be used. The communication links may be open links. An open link isan established link permitting data to flow from source to destinationwithout requiring either the client or the server to request data fortransmission. Open connections may be maintained by sending statuspackets or queries between the server and the client. The connectionlinks 130, 140 may occur over the Internet, over an intranet or over anyother type of communication network.

The client may be an application running on any computing device, suchas, for example, a PC, Mac, PDA, mobile phone, etc.

FIG. 2 shows a dual communication system 200 between a server 120 andfour clients 110 operating on one or more computers according to oneembodiment of the invention. As shown, the four clients are incommunication with the server using two communication links 130, 140. Ofcourse, any number of clients 110 may be coupled with the server 120using two communication links. The clients 110 may be coupled with theserver 120 over the Internet, over an intranet or any other type ofcommunication network. One or more clients may be running as anapplication on the same computer. Users may run more than one instanceof a client application and/or be logged in as more than one user.

FIG. 3 shows a client 110 and a server 120 with client and servercomponents according to one embodiment of the invention. In thisembodiment, the client 110 includes a JABBER client 111 and a web client112. The JABBER client 111 is in communication with a JABBER server 121over the open connection 130. The web client 112 is in communicationwith a web server 122 over an HTTP connection 140.

FIG. 4A shows more detail of components 400 within a client 110 andserver 120 according to one embodiment of the invention. The client 110includes an application 113, an open client 111, a web user agent 112,and a development environment 114. The application 113 coordinates inputfrom a user through a user interface and information from the serverthrough the communication links 130, 140. The application may bestand-alone software embedded in a storage medium on a computer andoperable through a computer processor. The application may run asmultiple instances on the same computer.

The web user agent 112 communicates with the web server 150 throughcommunication link 140. The web user agent 112 may fetch data from orsubmit data to the web server using, for example, HTTP. Various othertransfer protocols are known in the art and may be used by a web useragent to send and receive files from the web server 150.

The open client 111 communicates with the open connection server 121through communication link 130. The open client may be an instantmessaging client. The communication link 130 may be an opencommunication link. The open client 111 may receive an instant messagefrom the open connection server 121. The open connection server 121 andthe open client 111 may utilize any instant message protocol. Forexample, the open connection server 121 and open client 111 maycommunicate using Gadu-Gadu, Cspace, IRC, Meca Network, MCNP, OSCAR,PSYC, TOC, TOC2, XMPP, SIP/SIMPLE, YMSG, DirectNet, Zephyr, Gale and/orSkype. Other protocols may also be used.

The development environment 114 is the environment used to develop theclient 110. Various development environments are known in the art andmay be used to program and code the client 110.

The server 120 includes an open connection server with an openconnection server 170 and a persistent data server 160. Other serversmay be implemented with the server 120. Within these two servers 160,170 are various other components. The persistent data server 160includes an open client 113-A and a web server 150. The open client113-A is in communication with the open connection server 121. Thepersistent data server 160 also includes a data access layer 161 incommunication with a database 180. The data access layer 161 pullsfiles, updates files and creates files in the database 180. Anapplication server 162 may also be included. The persistent data server160 is developed within a program environment 163 open connection server170 also includes an open client 113-B in communication with the openconnection server 121 as well as a data access layer 162-B and a programenvironment 163-B.

FIG. 4B shows specific exemplary components 400 within a client 110 andserver 120 according to one embodiment of the invention. In thisembodiment, the open connection server 121 is a JABBER server 121 andthe open clients are JABBER clients 111, 113. The Web client is an HTTPclient 112. The database is a MySQL database 180. The applicationservers 162 are Java application servers and the program environment isa Java 1.5 environment 163. The development environment is the .Net 2.0environment. The web server is Java server pages (JSP) 150. Furthermore,the connection between the HTTP client 112 and the JSP 150 is an HTTPconnection and the connection between the JABBER server 121 and theJABBER client 111 is an open connection. In one embodiment, this openconnection streams XML.

FIG. 5 shows a flowchart 500 describing a method of instantly displayingupdated data at a client system in a network configuration according toone embodiment of the invention. The client establishes an open JABBERconnection with a server 505 and an HTTP connection with a server 510. Adata file is requested from the server through the HTTP connection 515.The data file is then sent to the client through the HTTP connection520. The data file may include HTML and may be displayed to a user atthe client through a user interface 525. For example, a user may requesta web page from a server. The web page is retrieved from the server andthen displayed on the screen of the computer used by the user.

A message from the JABBER server is then received by the client throughthe JABBER connection 530. The message may instruct the client torefresh the data file because the data file has been updated. The datafile is requested through the HTTP connection 535 whereupon the updateddata file is transmitted from the server and received at the client 540.The data file is then displayed again to the user through the userinterface 545.

FIG. 6 shows another flowchart 600 describing a method of instantlydisplaying updated data at a client system in a network configurationaccording to one embodiment of the invention. This embodiment is similarto the embodiment discussed above in regard to FIG. 5. The embodimentfollows the embodiment discussed in regard to FIG. 5 until the data fileis displayed at block 525. A message may then be received from theserver through the JABBER connection 550. In this example, the messageis an addendum to the data file. The data file is updated using themessage 555. The appended data file is then displayed 560.

FIG. 7 shows a flowchart 700 describing a method of instantly displayingupdated data at a client system in a network configuration according toone embodiment of the invention. In this embodiment, a JABBER and anHTTP connection are established 505, 510 between a client and a server.A data file is requested from the server by the client through the HTTPconnection 515. The data file is sent by the server and received at theclient through the HTTP connection 520. The data file is then displayedthrough a user interface at the client 525. The data file may include amarkup language such as HTML, XHTML, XML or any other mark up language.The data file may be displayed in a file specific application, aspecialized web browser and/or a standard web browser. The data file mayinclude an instant message conversation. The data file may also includecolor schemes and/or preferences.

A message is received at the client from the user through the userinterface 565. The message may include text, data, media, pictures,images, widgets, movies, music, changes to the data file, a markuplanguage, such as HTML, etc. A markup language version of the message iscreated 570 and the markup language version of the message is displayedwith the data file through the user interface 575. The markup version ofthe message is also sent to the server 580. The server may forward themarkup version of the message to other clients and/or save the markupversion of the message within the data file.

FIG. 8 shows a flowchart 800 describing a method of managing an instantmessaging server according to one embodiment of the invention. A firstdata file is maintained on the server 805 and may be accessible bymembers of a group. A connection is made from the server to a firstclient and to a second client 810, 815. The first data file is sent tothe first and second clients 820. After the first data file is sent tothe first and second clients, the connections may be closed. An openconnection between the first client and the server and the second clientand the server is made 825, 830. The first client sends a message to theserver through the first open connection 840. The message is thenforwarded to the second server 845. The first data file is appended withthe message received from the first client 850 and the first data fileas appended by the message from the first client is maintained 855 atthe server.

The open connections between the first client and the server and thesecond client and the server may be established before or after thefirst data file is sent to the server. Other clients may request thefirst data file. The data file may be sent to other clients with theappended data from the message received from the first client. Otherclients may also send messages to the server, have those messagesforwarded to the other clients and have the first data file appendedaccordingly. Furthermore, multiple data files may be maintained at aserver.

FIG. 9 shows another flowchart 900 describing a method of managing aninstant messaging server according to one embodiment of the invention.In this embodiment, a first data file is maintained at the server 805.Connections are made with more than one client 905. The first data fileis sent to the more than one client through the connections 910. Asecond connection is established between the more than one client andthe server 915. The second connection may be an open connection. Amessage is received at the server from one of the more than one client920 and is forwarded to the other clients connected to the server 845.The first data file is also appended 850 and saved at the server 855.

FIG. 10 shows a flowchart 1000 describing a method of managing a groupinstant messaging server according to one embodiment of the invention. Agroup list is maintained 1005. The group list may include informationrelated to the group and/or the individual group members. The group listmay include personal information, settings, preferences, IP addresses,aliases, passwords, encryption keys, etc. The group list may be saved ina group list database 1006.

At least one data file, a first data file, is maintained 805 in a datafile database 1011. A connection is established 905 with each onlinegroup member, and the first data file is sent to each online groupmember 910. These connections may occur at different times and the firstdata file may be sent to each online group member at different times.Once the first data file has been sent and received, each connectionbetween the server and the online group members may be closed. An openconnection may be established with each group member 915. A message isreceived from one group member through the open connection 920. Themessage is then forwarded to each member in the group 845. The firstdata file is appended with the data in the message 850 and stored in thedata file database 1011. The first data file is maintained 855 in thedata file database 1011. At some point a new member of the group comesonline and/or signs in 930, whereupon the appended first data file issent to the new member in the group 935.

FIG. 11A shows a method 1100 of determining whether a new user mayparticipate in a group according to one embodiment of the invention.Users may gain access to groups in a variety of ways. One embodiment ofthe invention determines whether a user has the appropriate privilegesto access group information. A group list is maintained 1005 in a grouplist database 1001. The group list includes whether the group ispassword protected, whether the group is public or private and/orwhether group entry requires an invitation or not. A user first requeststo participate in the group 1005. The system then determines whether thegroup is public 1110. If the group is public, then participation isallowed. Otherwise, the group is private and the system may determinewhether the user is a member of the group 1115. Membership informationmay be included in the group list. If the user is a member,participation is allowed 1135. Members may be asked to provide apassword or other authentication scheme. If the user is not a member ofthe private group, the user may be able to participate in the group byproviding a password 1120. If the password is correct, access to thegroup is allowed. The password may or may not provide membership to thegroup. In some embodiments, the password may be a one time use passwordor may limit participation. If a password is not provided, a user maygain access to the group by requesting group membership to the groupowner 1125. Some groups may not allow group membership requests andparticipation would then be denied 1130. Otherwise, a participationrequest is sent to the group owner or group members that approve groupmembership requests 1125.

FIG. 11B shows a method 1150 of inviting a user to join a groupaccording to one embodiment of the invention. The owner of the group orany authorized member may send an email message with a membershipinvitation 1152. The user receives the invitation in email 1154 or in agroup messaging application. The user may then decide whether to jointhe group or not 1156. If the user does not want to join the group hemay simply ignore the email from the owner of the group and he is notentered into the group 1158. If the user received the invitation messagein a group messaging application, he may be presented with options tojoin or not join. The user may then simply select his preference, forexample, on a button. If the user chooses to join the group he may bedirected to a web page or a card within the application may open wherehe can enter personal details or confirm his identity. If the useralready has a user ID 1160 then the group membership database is updated1164 and he is entered into the group. If the user does not have a userID he may be directed to create one 1162, prior to having the groupmembership database updated 1164.

FIG. 11C shoes a method 1170 for dealing with requests to join a groupaccording to one embodiment of the invention. The request may come fromblock 1125 in FIG. 11A. The owner receives a request from a user to joina group at 1172. The request may be received within a group applicationor may be received via email. The owner then decides whether or not toallow the user to join the group at 1174. If the owner so desires,membership may be rejected at 1176 or permitted at 1178. If membershipis permitted 1178, then the membership database is updated to includethe new user 1180 and a message is sent to the user letting him know heare in the group at 1182. The user may also be required to create a userID if he doesn't presently have one.

FIG. 12A shows a screenshot 1200 of various features of a groupmessaging application according to one embodiment of the invention. Agraphical user interface is shown including a toolbar 1220, four activecards 1230, an inactive card 1240, a menu bar 1260, and a minitablisting bar 1250. A group may include any number of cards. Each card canbe considered part of the group conversation. In general, users maycreate cards and add to content on existing cards. Specifically, a cardmay include IM functionality where users in a group may carry on aconversation. The messages may be displayed using a markup language suchas HTML or XML.

The toolbar 1220 presents a variety of different views for the user toselect from. FIG. 12A shows the “SD Friends” window as the activeviewable window. Other windows may be activated and viewed by simplyselecting the tab representing the window. For example, the “Yale SOM”window may be activated by selecting the “Yale SOM” tab 1222. Variousmanagement tabs may also be present. As shown a “Welcome” tab is shown.Other tabs representing other windows such as settings, profiles,search, adding groups, deleting groups, etc may also be included in thetoolbar 1220.

Four active cards 1230 are shown. Each card 1230 is part of the overallgroup conversation and may be started by any member in the group. Eachcard may include any format and present a variety of information. Forexample, a card may include group messages 1230A, 1220-C, embedded media1230-B, and/or a group poll 1230-D.

Cards can be customized according to one embodiment of the invention. Auser or group of users can create a card that has a unique orpersonalized look. This unique or personalized look can be specific toone or more groups, or can be specific to all of the groups to which auser belongs as a whole. For example, each user within a group may beassigned a card color; every time the user sends a message to a group,the card that contains his message may be that unique color. This wayone can identify, which user sends which messages, among other thingsand other methods.

A user can customize a card through settings. Customizations can includebut are not limited to: selecting the card's color, background images,selecting the background color, size and font of the text on the card,selecting an image to appear on the card, adding animation, selectingmedia to appear on the card; applying widgets to the card; etc. Adefault customization may also be selected whereby new cards are openedwith the default customization. Customizations may also be saved in acascading style sheet (CSS) file. The CSS file may provide customizationto s single card and may be used to apply the customization by defaultto all other cards. Also, the CSS file provides for a simpler HTML orXML code within each card by saving the card presentationcharacteristics in the CSS file while the content is maintained within amarkup language file. The CSS file may be saved locally on the computerrunning the application and/or the CSS file may be maintained on aserver.

Also, a group of users may have their cards customized automaticallyaccording to one embodiment of the invention. For example, a company ororganization can decide that it would like everyone in its company ororganization to have its company or organization's logo on every cardsomeone in its company or organization sends. The application can set acertain group of people to have card customizations like this or othersas a group. Its cards may all look alike, or the cards can be similar inonly one or more respects, such as all having the company logo on itscards, but having all other card customizations selectable by the user.In some cases the user can override the card customizations that havebeen set for them as a group; in some cases, the user cannot do so.

Groups that are to share certain card customizations can be establishedbased on any number of methods. These methods include but are notlimited to: everyone with an email address from a certain domain can beset to share the same customizations. For example, everyone with anemail address from a certain company can have that company's logoautomatically display on their cards. Also, a pool of email addresses orusemames can be set up to share certain card customizations. Other waysof grouping users who are to share the same card customizations are alsopossible.

According to one embodiment of the invention, cards can also be set toappear not as cards at all, but as messages contained within groups inpurely a text (or any other) format, not entirely unlike the way thatmessages are exchanged within standard instant messengers. The messageswould still be grouped within the groups to which they belong. Cards canalso be dragged directly onto the desktop. When a card has been draggedonto the desktop, the card can be set to dynamically display the mostcurrent message in a group. The card can also be set to dynamicallydisplay the most recent message sent by a particular user. The card canalso remain as a static message. The card can also be a blank card thatcan be ready to accept a new message to be sent to a group. The card canalso be configured to display a certain message according to any otheralgorithm or set of preferences. Group tabs can also be customized bythe group owner (or another entity) in any number of methods.

In another embodiment, the menu bar 1260 may also have a button thatopens a new card in the application. The new card may, by default, be aninstant messaging card. The card may also be styled according to userand/or group preferences.

Cards may contain messages. In some embodiments, there is one messageper card. Each card may contain certain details that are relevant to themessage and/or sender-specific to that card. Each card may containdetails such as, but is not limited to, the sender's user name, the dateand time the message was sent or received, the message (which cancontain text, audio, video, files, links, or any other data), etc.Within the card links may be included that include, but are not limitedto: Profile (allows the sender's profile to be viewed), Email (allowsthe sender to be directly emailed), IM (allows a traditional IMconversation with the sender to be initiated), Web Page (allows thesender's web page to be accessed), etc. The card may also indicate theonline status of the sender. The status may vary depending on what theuser is doing. In other embodiments, the status may include an editablemessage by the user. For example, when the user is online and able toparticipate, the status may indicate “online”. When the sender is onlinebut has experienced a period of inactivity the status may be indicatedas “away”. When the user is not logged into the system the status may be“offline”. Various other status indicators may be used.

An inactive card 1240 is also shown. The inactive card 1240 allows agroup member to create a new card. A card creation and/or customizationwindow may open when the user selects the “create a new card” link within the inactive card 1240. The new card is placed within the userinterface. Once a new card is created, a new inactive card may bepresented. In another embodiment of the invention, the new card is an IMcard by default. Changes may be made to a default card, for example, byediting the mark up language.

Cards can be customized. A user or group of users can create a card thathas a unique or personalized look. This unique or personalized look canbe specific to one or more groups, or can be specific to all of thegroups to which a user belongs as a whole. By default, each user withina group is assigned a card color. This means that every time that usersends a message to a group, the card that contains his message may bethat unique color. This way one can identify which user send whichmessages, among other things and other methods. The status may also beedited and/or customized by the user.

A user can customize his card through settings. Customizations caninclude but are not limited to: selecting the card's color, selectingthe color, size and font of the text on the card, selecting an image toappear on the card, etc. Also, a group of users can have his cardscustomized automatically. For example a company or organization candecide that he would like everyone in his company or organization tohave his company or organization's logo on every card someone in itscompany or organization sends. The system can set a certain group ofpeople to have card customizations like this or others as a group. Iscards can all look alike, or the card can be similar in only one or morerespects, such as all having the company logo on his cards, but havingall other card customizations selectable by the user. In some cases theuser can override the card customizations that have been set for them asa group; in some cases, the user cannot do so.

These groups that are to share certain card customizations can beestablished based on any number of methods. These methods include butare not limited to: Everyone with an email address from a certain domaincan be set to share the same customizations. For example, everyone withan email address from a certain company can have that company's logoautomatically displayed on his cards. Also a pool of email addresses orusernames can be set up to share certain card customizations. Other waysof grouping users who are to share the same card customizations are alsopossible.

Cards may also include instant messaging 1230-A, 1230-C. Messages may beadded to the list of messages by entering text into the text field. Whena message has been added, each member of the group that is onlinedisplays an update to the card that includes the new message. Users mayedit posted messages after the message has been posted in the card.Users may also include markup language in their messages. A URL may beentered into the text field and the Web page or files associated withthe URL may be rendered and displayed within the card rather thandisplaying the URL link to the web page or files.

Users may also edit and delete past messages within a card. Theinformation presented in a IM card is dynamic and may be edited ordeleted by the user. Those edits may be sent to the rest of the group.For example, a user may be writing an instant message and he sends themessage. The user may have a typo in the message or regret that he sentthe message. The user may then simply edit the message within the cardand those edits may be sent to the group as well as to the data file onthe server where the group data persists. The system may limit edits anddeletes only to the last version or for a certain time period.

The menu bar 1260 may contain information with details about the groupand buttons that enable key actions related to that group or othergroups. Details include but are not limed to details such as the group'sage, owner, the number of messages that have been sent to that group,the security level of that group, etc. Buttons enable users to create agroup, leave or delete a group, invite a user to a group, remove a userfrom a group, search for groups, search for users, and do other things.

The Menu bar may also contain buttons. Many of these buttons may bespecifically related to the visible group, while some of them may not.These buttons include but are not limited to: Edit Profile (users cancreate a profile of themselves that others can view), Settings (userscan choose to personalize many settings and customizations), CreateGroup (users can create groups), Delete or Leave Group (users can deleteand/or leave groups), Find Group (users can search for groups andrequest to be invited to groups), Add User (users can add or inviteusers to their groups), Remove User (users can remove users from theirgroups), Find Users (users can search for other users and then invitethem to their groups if desired), etc. Another button may be included toopen up card widgets that have been created by others in the group or bythe user of the group.

The menu bar 1260 may also include the group name rather than the groupnumber. When a user enters a group name in a search box within theapplication, the group name may be translated into a group number andthe user may be directed to that group's profile. If the user is amember, he may be transferred automatically to the group and beginparticipation. A user may also search for members within the search bar.

The minitab listing bar 1250 may include a number of minitabs. In thisembodiment of the invention, three minitabs are shown: Members 1250-A,Conversations 1250-B, Files 1250-C. The members' minitab is open andshows the members in the current group. The members may be listed in anymanner and may include a variety of member information. In thisembodiment, the user name, a user image, the user status (typing, away,offline) and whether the user profile have been updated. The members'individual profiles may be viewed by selecting the user's name and/orimage.

FIG. 12B show the “Conversations” minitab 1250-B. In this minitab, theusers' conversations are listed in reverse chronological order. Thenumber of messages within each conversation is also shown. Theconversations listed in the conversations minitab 1250-B relate to cardswithin a group window.

FIG. 12C show the “Files” minitab 1250-C. Files are included that may beaccessed by group members within the “Files” minitab 1250-C. A user mayadd files by simply dragging and dropping a file icon or by clicking onthe upload button. Files may be downloaded and/or opened by selecting adownload button. Files may also be saved to another location on theuser's computer by dragging and dropping the file from the application.

FIG. 12C also shows a text mark up window 1270 that may be used tomarkup text entered into a card and sent to the other group members. Inthis embodiment, text may be bolded, underlined, and/or italicized. Thetext size may be adjusted and characters may be added. Any variety oftext markups may be included. The text markup window may be customizedand shared to include other markup characters.

FIG. 13 shows a screenshot 1300 of a pop-out card 1305 of a groupmessaging application according to one embodiment of the invention. Thesize of a card may be increased and popped-out into a larger individualwindow by selecting the pop-out button 1310. The card may be returned toits normal size and position by selecting the pop-in button 1312.

FIG. 14 shows a screenshot 1400 of a welcome screen 1400 of a groupmessaging application according to one embodiment of the invention. Thewelcome screen is shown when the welcome tab is selected. The welcomescreen 1400 includes a list of groups 1405 that the user participatesin, a list of friends 1410, and a list of tags 1415 in a tag cloud. Thelist of tags 1415 may graphically reflect the relevance, importance orpopularity of a topic. As shown, the larger the text of the topic, themore popular the term. A user interested in a topic associated with atag may simply click on the tag and the related information may beopened in an existing card or in a new card.

Ad space 1420 may also be added to the welcome screen 1400 and/or onscreens throughout the application. The ads may be topic-specific basedon current information being displayed through the cards. Furthermore,as conversations progress, the ads may adapt to provide ads related toconversations. For example, if users are discussing cars through aninstant messaging card ads may be displayed for cars and morespecifically for cars or similar cars being discussed. As theconversation progresses, for example, the users may discuss football andthe ads may change to ads for football, such as, for example, forfootball paraphernalia or tickets.

FIG. 15 shows a screenshot 1500 of a decision window of a groupmessaging application according to one embodiment of the invention. Thedecision screen is shown when the decisions tab is selected. Thedecision window lists decisions to be made by the user. Typically,decisions revolve around joining groups or contacts. As shown, onedecision is whether to let Bill Baker join the user's contacts 1510.Another example shown is that Tim has invited the user to join his groupRock Stars 1520 and the user can decide what to do (reject or accept theinvitations). And, Olga wants to know if she can join the user's AppleLovers group. Here at the decision window, the user may accept or denythese requests.

FIG. 16 shows a screenshot 1600 of a card editor of a group messagingapplication according to one embodiment of the invention. A card editorallows users to create a customized card within a group. Cards may alsobe saved and used in a variety of groups. Custom cards may include HTML,XML or any other markup language to present information to a group. Thecard editor, in this embodiment, includes a name and description field1610. The markup language code, in this case HTML, is editable in field1620. An icon may be associated with the card in field 1630. Variousoptions and settings may also used for a card editor as shown in field1640. Cards may be made public or private, shared in a group or groups,and/or kept personal. Buttons for saving and/or sharing a card are alsoavailable. Finally, in the card editor shown, a preview of thecustomized card may be displayed.

In another embodiment of the invention, users may create card widgets. Acard widget is a portable and specialized card that includes a chunk ofcode that can be opened by any user and may display the code. Cardwidgets may be coded in HTML as shown. The card widget may also useFlash or JavaScript. For example, a user may create a portable poll cardwidget for polling users. The card widget can then be saved and sharedwith other users. Other users may then use the card widget in variousgroups. Examples of card widgets may include, maps, weather pages,games, puzzles, layout, and/or other customizations. Card widgets areonly bounded by the creativity of the users creating the card widgets.Also, card widgets may associated with a button on the menu bar 1260,whereupon when the button is selected the widget either pops-up into anew window or is entered as a new card within the application.

FIG. 17 shows a screenshot 1700 of a popular groups window of a groupmessaging application according to one embodiment of the invention. Apopular groups window may be selected by selecting a popular tab or byselecting a link. The popular groups window displays a list of populargroups 1710, users 1720 and/or cards 1730. Information related to thegroup, user or card may also be displayed. The group, user or card maybe selected and viewed separately, if permitted depending on groupmembership and whether a group, card, or user information is public orprivate.

FIGS. 18A-F shows screenshots 1800 of a user profile in a groupmessaging application according to one embodiment of the invention. Userprofiles may present information about a user. A user may choose apublic or private profile, or a semi-public profile. FIG. 18A shows ascreen 1810 explaining a user's profile is private and that it may beviewed if the user is part of a group with the viewer and/or in theviewer's list of groups. A semi-private profile displays someinformation publicly and withholds other information from viewers in theusers groups or contacts.

FIG. 18B-F shows an exemplary user profile pages. The user profile listsvarious details about a user, such as, for example, email address,photograph, address, telephone number, title, quotes, status, group andcontact statistics, video, instant messaging user ids, personal webpages, favorite movies, favorite music, favorite television shows,favorite web pages, work position, employment, education, groupmembership and/or contacts. Of course, various other information may bepresented in a user profile. Users may also modify and/or customize hisuser profile.

FIG. 19 shows a screenshot 1900 of a group profile in a group messagingapplication according to one embodiment of the invention. The groupprofile may describe the purpose and/or association of the group. Thegroup profile may also list group details such as number of members,number of cards, number of messages, number files, date created,creator, public and private information, related groups, etc.

FIG. 20 shows a screenshot 2000 of group settings in a group messagingapplication according to one embodiment of the invention. Group settingsuch as group name, description, and whether the group is public orprivate may be changed. Such information may be changed only by thegroup owner or manager. A photograph or video may be included in thegroup settings.

FIGS. 21A-C shows screenshots 2100 of a user invitation window in agroup messaging application according to one embodiment of theinvention. As shown in FIG. 21A, people may be invited to join a groupby sending a message. Email address or usernames 2110 may be entered forindividuals to be invited to the group. Invited individuals may thenreceive a message within the application or via email inviting them tojoin the group. FIG. 21B shows a personal message that may be includedin the group invitation message. FIG. 21C shows a list of usernames andemail addresses that have been invited to join the group 2130. Usernamesand ids that were not recognized may also be displayed 2140.

FIG. 22 shows a screenshot 2200 of group booting window in a groupmessaging application according to one embodiment of the invention. Agroup owner may boot others from the group. A group owner may simplyselect members of the group from a list 2210 and choose to have themremoved (booted) from the group. Removed members may be re-invited.

FIG. 23 shows a screenshot 2300 of premium group settings in a messagingapplication according to one embodiment of the invention. Premium groupsmay also be established that require payment for entry into the group.Newspapers, movies, televisions shows, rock bands, celebrities, etc. maycreate premium groups that provide premium content and interaction forusers that pay for group membership. Membership may be a one time fee ora recurring fee. Premium membership may include a one time eventmembership.

In another embodiment of the invention a client application may storefinancial or payment information that may be used to pay for applicationservices, content, premium content, widgets, card widgets, groupmembership, premium groups, or other Internet based transactions. Usersmay participate in a marketplace where goods and services may be boughtand sold. User's financial and/or transaction information may bemaintained by the client application and provided to financialinstitutions for payment of a good and/or service. The financial and/ortransaction information may be saved locally on the computer where theclient application is running or on a server. For example, a user mayenter their credit card number and other billing information. When theuser wishes to make a purchase the client application provides therelevant payment information. The user may need to provide a password orother security code to release the payment information.

FIG. 24 shows a screenshot 2400 of a group creation window in a groupmessaging application according to one embodiment of the invention. Auser can create groups by clicking on a “Create Group” button. The usercan create a group name, add a group description, and set any number ofother attributes related to that group. When a user creates a group,that user is considered the “owner” of that group. Being the owner of agroup enables a user to control many aspects of that group. Thisincludes, but is not limited to: inviting users to that group, kickingoff users of that group, sharing ownership with other users, un-sharingownership with other users, transferring ownership to other users,restricting other's functional capabilities within that group, etc. Ifdesired, a group can be set up such that everyone in the group is anowner of the group or more than one person is an owner of a group.

FIGS. 25A-D show various features of the embodiments described in FIGS.11A-11C according to one embodiment of the invention. FIG. 25A shows ascreenshot of a card editor. The card editor provides a user a way ofselecting pre-designed cards for use in their application and forsharing amongst their groups. These cards may include card widgets. Somecards may require a fee to use. A search function provides users a wayto find various types of cards.

FIG. 25B shows a screenshot of card management according to oneembodiment of the invention. A user may view the active cards in theirgroups and where the cards are placed. Various settings may be includedin this view. Cards may be on the toolbar. Cards may be shared ordeleted.

FIG. 25C shows a screenshot of how a user may edit the HTML code of acard according to one embodiment of the invention. A card name anddescription may be entered, and a card icon may be selected The user mayalso be able to chose whether the card is listed publicly or not.

FIG. 25D shows a screenshot of how to send a card to groups orindividuals according to one embodiment of the invention.

In another embodiment of the invention, group information persists at aserver. Accordingly, a user may use a group messaging application at anycomputer by logging into their account. The application may query thegroup list database at the server and the groups within which the useris a member are opened within the application.

In another embodiment of the invention, messages persist at a server.Accordingly, a user may review past messages within a group. Completeconversations and cards persist at the server and are sent to the IMapplication. Furthermore, IM application settings also persist at theserver. When a user logs into an IM application, the IM applicationqueries the server for updated conversations, messages, and other groupdata that persists at the server.

Group membership and access to group messages and/or content persist ona server. Membership in a group is maintained beyond a single onlinesession. Group messages and content also persist on a server.

Messages are also persistent. Messages remain in place even if a userlogs off the network and then logs back into the network. Logging in andout, moving from online to offline mode, or any other similar activitydoes not cause messages to go away. Messages can only go away when theyare manually deleted or otherwise automatically deleted as with normalmessaging handling rules of the system. However, logging in and out ofthe system, again, or moving from online to offline mode or vice-versadoes not cause messages to go away. Messages can be stored on the harddrive and refreshed upon each time there is an active connection to thenetwork. Similarly, messages can be stored chiefly on the server.Messages can be stored in other ways as well.

Users can send messages to groups via standard email according to oneembodiment of the invention. A user can send messages to a group bysending the message via email to an address such as, for example,owner.group@gogroups.com, group.owner@gogroups.com and/orgroup#@gogroups.com. Owner in this case is the screen name of the groupowner, and group is either the group name or the group number that theowner owns. If these match a group that exists and people belong to,then the message may appear in the group as do other messages. There maybe a notation on that message that it arrived by email. If the groups isa private group, that is a group that only allows messages from approvedgroup members, the application may forward the message to the group onlyif the email address from the sender matches an email address in thegroup member list. Otherwise, the application may not send the messageto the group. The message may appear in an instant messaging card, agroup email message card, and/or sent to each group member's emailaddress.

Similarly, a user can setup their preferences to have messages deliveredto particular groups forwarded to an email address based on certaindefinable events. When these messages are received by email, the usercan reply to them and have their response delivered to the group toappear as a message. There may be a notation on that message that itarrived by email. The user can also have messages delivered to aportable device such as a mobile phone using SMS. Users may also respondand send messages to the group from a mobile device using SMS. Anotation may also be included that the message arrived from a mobiledevice using SMS.

Cellular phones and personal digital assistants (PDAs) can send messagesto a group by sending a message to an appropriate number with or withouta designated code to indicate to which group the message should be sent.Other designators may be used to specify the card within a group wherethe message should be displayed. Such messages may contain text, images,video, audio and/or any other data, including data describing certainattributes of the data, such as the location (in latitude/longitude orother form), time and/or other details of from where, when, how and bywhom it was sent. Once received, the message may appear in thedesignated group as do other messages. There may be a notation on thatmessage that it arrived by cellular phone or other wireless device.

Similarly, a user can setup their preferences to have messages sent toparticular groups forwarded to a wireless device. These messages can besent via SMS, MMS, WAP, Internet, or any other transmission method.Messages may also be received from a wireless device with SMS, MMS, WAP,Internet, or any other transmission method.

In another embodiment of the invention, users can click on a buttonwithin a group to initiate a voice and or video conversation that may beaccessible and shared with everyone else belonging to that group. Voiceand/or video shared with members of a group can be live or recorded andmay persist on the server.

Families can be established. Families are groups of users that want tobe united in unique ways for any number of reasons. For example, afamily can be established such that only users belonging to that familycan communicate with each other. Families can then en masse be enabledto communicate with other families or with users not in families orusers in the pubic family at once. Families can also be established sothat certain families can share access to certain features orcustomizations.

Specific details are given in the above description to provide athorough understanding of the embodiments. However, it is understoodthat the embodiments may be practiced without these specific details.For example, circuits may be shown in block diagrams in order not toobscure the embodiments in unnecessary detail. In other instances,well-known circuits, processes, algorithms, structures, and techniquesmay be shown without unnecessary detail in order to avoid obscuring theembodiments.

Implementation of the techniques, blocks, steps and means describedabove may be done in various ways. For example, these techniques,blocks, steps and means may be implemented in hardware, software, or acombination thereof. For a hardware implementation, the processing unitsmay be implemented within one or more application specific integratedcircuits (ASICs), digital signal processors (DSPs), digital signalprocessing devices (DSPDs), programmable logic devices (PLDs), fieldprogrammable gate arrays (FPGAs), processors, controllers,micro-controllers, microprocessors, other electronic units designed toperform the functions described above and/or a combination thereof.

Also, it is noted that the embodiments may be described as a processwhich is depicted as a flowchart, a flow diagram, a data flow diagram, astructure diagram, or a block diagram. Although a flowchart may describethe operations as a sequential process, many of the operations can beperformed in parallel or concurrently. In addition, the order of theoperations may be rearranged. A process is terminated when itsoperations are completed, but could have additional steps not includedin the figure. A process may correspond to a method, a function, aprocedure, a subroutine, a subprogram, etc. When a process correspondsto a function, its termination corresponds to a return of the functionto the calling function or the main function.

In yet another embodiment of the invention, voice over IP (VOIP)functionality may also be included. The JABBER server and JABBER clientsmay include VOIP functionality using the Jingle protocol over an openconnection. Real time transport protocol (RTTP) may also be used. Inanother embodiment of the invention, a client application running on acomputer with a webcam may send live video to a group through the JABBERclient.

As used throughout the terms markup language, HTML and XML include anyinformation that may be included in a web page. For example, the termsmay include data such as text, images, videos, audio, as well as markuplanguage coding that describes the structure or presentation of theinformation in the data. Various types of markup languages may be usedbesides XML and HTML.

Furthermore, embodiments may be implemented by hardware, software,scripting languages, firmware, middleware, microcode, hardwaredescription languages and/or any combination thereof. When implementedin software, firmware, middleware, scripting language and/or microcode,the program code or code segments to perform the necessary tasks may bestored in a machine readable medium, such as a storage medium. A codesegment or machine-executable instruction may represent a procedure, afunction, a subprogram, a program, a routine, a subroutine, a module, asoftware package, a script, a class, or any combination of instructions,data structures and/or program statements. A code segment may be coupledto another code segment or a hardware circuit by passing and/orreceiving information, data, arguments, parameters and/or memorycontents. Information, arguments, parameters, data, etc. may be passed,forwarded, or transmitted via any suitable means including memorysharing, message passing, token passing, network transmission, etc.

For a firmware and/or software implementation, the methodologies may beimplemented with modules (e.g., procedures, functions, and so on) thatperform the functions described herein. Any machine-readable mediumtangibly embodying instructions may be used in implementing themethodologies described herein. For example, software codes may bestored in a memory. Memory may be implemented within the processor orexternal to the processor. As used herein the term “memory” refers toany type of long term, short term, volatile, nonvolatile, or otherstorage medium and is not to be limited to any particular type of memoryor number of memories, or type of media upon which memory is stored.

Moreover, as disclosed herein, the term “storage medium” may representone or more devices for storing data, including read only memory (ROM),random access memory (RAM), magnetic RAM, core memory, magnetic diskstorage mediums, optical storage mediums, flash memory devices and/orother machine readable mediums for storing information. The term“machine-readable medium” includes, but is not limited to portable orfixed storage devices, optical storage devices, wireless channels and/orvarious other mediums capable of storing, containing or carryinginstruction(s) and/or data.

While the principles of the disclosure have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the disclosure.

1. A network communication method at a client, wherein the clientincludes at least a first file, comprising: establishing a first andsecond connection between the client and a server, wherein the firstconnection comprises an open connection and the connections are notnecessarily established at the same time; and receiving a message fromthe server through the first connection, wherein the first messageinstructs the client to request first update data from the serverthrough the second network connection.
 2. The network communicationmethod of claim 1, further comprising requesting the first update datafrom the server through the second connection.
 3. The networkcommunication method of claim 1, further comprising updating the firstfile with the first update data.
 4. The network communication method ofclaim 1, further comprising displaying the first file to a user througha user interface.
 5. The network communication method of claim 1,wherein the message is received from the server substantiallyinstantaneously after the updated file is updated.
 6. The networkcommunication method of claim 1, wherein the first connection is aJABBER connection.
 7. The network communication method of claim 1,wherein the second connection is an HTTP connection and the filecomprises HTML.
 8. The network communication method of claim 1, whereinthe first file comprises a markup language.
 9. The network communicationmethod of claim 1, wherein the server comprises an HTTP server and aJABBER server.
 10. The network communication method of claim 1, furthercomprising: receiving second update data through a user interface; andupdating the first file with the second update data.
 11. The networkcommunication method of claim 10, further comprising sending the firstfile to the server through the first connection.
 12. The networkcommunication method of claim 10, further comprising sending the secondupdate data to the server through the second connection.
 13. The networkcommunication method of claim 10, further comprising converting thesecond update data into a markup language.
 14. The network communicationmethod of claim 10, further comprising displaying the first file to auser through the user interface.
 15. A network communication method at aserver, wherein the server includes at least a first file, comprising:establishing a first connection between a first client and the server;receiving first update data from the first client through the firstconnection and updating the first file with the first update data;establishing a second and a third connection between a second client andthe server, wherein the second connection is an open connection and theconnections are not necessarily established at the same time; sending amessage to the second client through the second connection, wherein themessage tells the client that first update data is available at theserver; receiving a message from the second client through the thirdconnection, wherein the message requests that the server send the firstupdate file; and sending the first update file through the thirdconnection to the client.
 16. The network communication method of claim15, wherein the server comprises a JABBER server and an HTTP server. 17.The network communication method of claim 15, further comprising:establishing a plurality of second and third connections between theserver and each of a plurality of clients, wherein the plurality offirst connections are open connections and the connections are notnecessarily established at the same time; sending a message to each ofthe plurality of clients through each of the plurality of secondconnections, wherein the message tells each of the plurality of clientsthat first update data is available at the server; receiving a messagefrom at least one of the plurality of clients through at least one ofthe plurality of third connection, wherein the message requests that theserver send the first update file; and sending the first update filethrough the third connection to each of the plurality of clients thatsent a message to the server.
 18. A network communication method at aserver, comprising: maintaining a first group list at the server,wherein the first group list comprises a list of more than one client,wherein the list of more than one client comprises at least a firstclient; maintaining at least a first file at the server; establishing aplurality of first connections between the server and a plurality ofclients, wherein the plurality of clients comprise at least the firstclient; sending the first file to the clients in the first group;establishing a plurality of second connections between the server andthe plurality of clients, wherein the plurality of second connectionscomprise open connections; receiving a first message from the firstclient, wherein the first message comprises an addendum to the firstfile, and the first message specifies that the message is intended forclients in the first group; appending the first file with the firstmessage; determining which of the plurality of clients with a secondconnection are in the first group list; and forwarding the message tothe plurality of clients in the first group list through the pluralityof second connections.
 19. The network communication method of claim 18,further comprising: establishing a third connection between the serverand a second client, wherein the third connection is an open connection;determining whether the second client is in the first group; and if thesecond client is in the first group, sending the first file to thesecond client through the third connection.
 20. A group instantmessaging method at a server, comprising: maintaining a group profile,wherein the group profile comprises a list of clients that are membersof a group; receiving a request from a first client to participate inthe group; and determining whether the first client is permitted toparticipate in the group.
 21. The group messaging method of claim 20,further comprising permitting the first client to participate in thegroup if the first client is a member of the group.
 22. The groupmessaging method of claim 20, further comprising permitting the firstclient to participate in the group if the first client is not a memberof the group and the group profile permits nonmembers to participate inthe group.
 23. The group messaging method of claim 20, furthercomprising forbidding the first client to participate in the group ifthe first client is not a member of the group and the group profile doesnot permit nonmembers to participate in the group.
 24. The groupmessaging method of claim 20, further comprising permitting the firstclient to participate in the group if the first client provides apassword associated with the group.
 25. A persistent group messagingsystem comprising: a network interface, wherein the network interface isadapted to communicate with a server through one or more communicationlinks; a user interface, wherein the user interface is adapted tocommunicate with a user; a processor; and a memory storage device,wherein the memory storage device includes instructions for theprocessor; wherein the instructions comprise: instructions to retrieveat least one group message file from the server through the networkinterface, wherein the group message file includes more than oneconversation; and instructions to display more than one conversation atthe user interface.
 26. The persistent group messaging system of claim25, further comprising: instructions to receive a message from the userthrough the user interface; instructions to amend the group messagingfile with the message; and instructions to send the amended groupmessaging file to the server through the network interface.
 27. Aninstant messaging application, comprising: a network interface, whereinthe network interface is adapted to communicate with a server throughone or more communication links; a user interface, wherein the userinterface is adapted to communicate with a user; a processor; and amemory storage device, wherein the memory storage device includesinstructions for the processor; wherein the instructions comprise:instructions to receive instant messages from the server through thenetwork interface; instructions to display the instant messages at theuser interface; and instructions to display ads at the user interface,wherein the ads are related to the content within the instant messagespresently displayed at the user interface and as the instant messageconversation progresses and the content changes the ads likewise changeto adapt to the changed content.
 28. A group instant messagingapplication, comprising: a network interface, wherein the networkinterface is adapted to communicate with a server through one or morecommunication links; a user interface, wherein the user interface isadapted to communicate with a user; a processor; and a memory storagedevice, wherein the memory storage device includes instructions for theprocessor; wherein the instructions comprise: instructions to receivemore than one instant message conversation from the server through thenetwork interface, wherein the instant messages comprise messages frommore than one user and comprise more than one conversation; andinstructions to concurrently display more than one instant messageconversation at the user interface.
 29. The group messaging applicationof claim 28, wherein each of the more than one instant messageconversations are displayed in a card.
 30. The group messagingapplication of claim 29, wherein each card is separately configurable.31. The group messaging application of claim 28, wherein the instantmessage comprises data selected from the group consisting of text,marked up text, video, audio, images, and data files.
 32. The groupmessaging application of claim 28, wherein the instant messagescomprises HTML data.
 33. The group messaging application of claim 29,wherein a card comprises a card widget.
 34. The group messagingapplication of claim 28, wherein the group comprises more than one user.35. A network communication apparatus comprising: a web user agent incommunication with a web server; an instant messaging client incommunication with an instant messaging server over an open connection;wherein the instant messaging client receives a message from the instantmessaging server informing the network communication apparatus that anupdated file is available at the web server and the web user agentrequests and receives the updated file from the web server.
 36. Anetwork communication server comprising: an open connection servercomprising an instant messaging client in communication with an instantmessaging server; and a persistent data server comprising an instantmessaging client in communication with an instant messaging server and aweb server in communication with at least one web client.
 37. Thenetwork communication server of claim 36, wherein the persistent dataserver and the open connection server are in communication withdatabase.
 38. An instant messaging method at a first client, comprising:receiving a widget from a user; associating the widget with a button ata client application associated with the first client; and distributingthe widget to a second client through a network interface.
 39. Theinstant messaging method of claim 38, further comprising: receiving asecond widget from a third client; and associating the widget with abutton at a client application associated with the first client.